<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Searching for Bugs</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="The Bugzilla Guide - 3.6.4 
    Release"
HREF="index.html"><LINK
REL="UP"
TITLE="Using Bugzilla"
HREF="using.html"><LINK
REL="PREVIOUS"
TITLE="Life Cycle of a Bug"
HREF="lifecycle.html"><LINK
REL="NEXT"
TITLE="Filing Bugs"
HREF="bugreports.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Bugzilla Guide - 3.6.4 
    Release</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="lifecycle.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 5. Using Bugzilla</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="bugreports.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="query"
>5.5. Searching for Bugs</A
></H1
><P
>The Bugzilla Search page is the interface where you can find
    any bug report, comment, or patch currently in the Bugzilla system. You
    can play with it here: 
    <A
HREF="http://landfill.bugzilla.org/bugzilla-3.6-branch/query.cgi"
TARGET="_top"
>http://landfill.bugzilla.org/bugzilla-3.6-branch/query.cgi</A
>.</P
><P
>The Search page has controls for selecting different possible
    values for all of the fields in a bug, as described above. For some
    fields, multiple values can be selected. In those cases, Bugzilla
    returns bugs where the content of the field matches any one of the selected
    values. If none is selected, then the field can take any value.</P
><P
>&#13;      After a search is run, you can save it as a Saved Search, which
      will appear in the page footer. If you are in the group defined 
      by the "querysharegroup" parameter, you may share your queries 
      with other users, see <A
HREF="userpreferences.html#savedsearches"
>Saved Searches</A
> for more details.
    </P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="boolean"
>5.5.1. Boolean Charts</A
></H2
><P
>&#13;        Highly advanced querying is done using Boolean Charts.
      </P
><P
>&#13;        The boolean charts further restrict the set of results
        returned by a query. It is possible to search for bugs
        based on elaborate combinations of criteria.
      </P
><P
>&#13;        The simplest boolean searches have only one term. These searches
        permit the selected left <EM
>field</EM
>
        to be compared using a
        selectable <EM
>operator</EM
> to a
        specified <EM
>value.</EM
>
        Using the "And," "Or," and "Add Another Boolean Chart" buttons, 
        additional terms can be included in the query, further
        altering the list of bugs returned by the query.
      </P
><P
>&#13;        There are three fields in each row of a boolean search. 
      </P
><P
></P
><UL
><LI
><P
>&#13;            <EM
>Field:</EM
>
            the items being searched 
          </P
></LI
><LI
><P
>&#13;            <EM
>Operator:</EM
>
            the comparison operator 
          </P
></LI
><LI
><P
>&#13;            <EM
>Value:</EM
>
            the value to which the field is being compared
          </P
></LI
></UL
><DIV
CLASS="section"
><H3
CLASS="section"
><A
NAME="pronouns"
>5.5.1.1. Pronoun Substitution</A
></H3
><P
>&#13;          Sometimes, a query needs to compare a user-related field
          (such as ReportedBy) with a role-specific user (such as the
          user running the query or the user to whom each bug is assigned).
          When the operator is either "equals" or "notequals", the value
          can be "%reporter%", "%assignee%", "%qacontact%", or "%user%".
          The user pronoun
          refers to the user who is executing the query or, in the case
          of whining reports, the user who will be the recipient
          of the report. The reporter, assignee, and qacontact
          pronouns refer to the corresponding fields in the bug.
        </P
><P
>&#13;          Boolean charts also let you type a group name in any user-related
          field if the operator is either "equals", "notequals" or "anyexact".
          This will let you query for any member belonging (or not) to the
          specified group. The group name must be entered following the
          "%group.foo%" syntax, where "foo" is the group name.
          So if you are looking for bugs reported by any user being in the
          "editbugs" group, then you can type "%group.editbugs%".
        </P
></DIV
><DIV
CLASS="section"
><H3
CLASS="section"
><A
NAME="negation"
>5.5.1.2. Negation</A
></H3
><P
>&#13;          At first glance, negation seems redundant. Rather than
          searching for
          <A
NAME="AEN2448"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              NOT("summary" "contains the string" "foo"),
            </P
></BLOCKQUOTE
>
          one could search for 
          <A
NAME="AEN2450"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              ("summary" "does not contain the string" "foo").
            </P
></BLOCKQUOTE
>
          However, the search 
          <A
NAME="AEN2452"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              ("CC" "does not contain the string" "@mozilla.org")
            </P
></BLOCKQUOTE
>
          would find every bug where anyone on the CC list did not contain 
          "@mozilla.org" while
          <A
NAME="AEN2454"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              NOT("CC" "contains the string" "@mozilla.org")
            </P
></BLOCKQUOTE
>
          would find every bug where there was nobody on the CC list who
          did contain the string. Similarly, the use of negation also permits
          complex expressions to be built using terms OR'd together and then
          negated. Negation permits queries such as
          <A
NAME="AEN2456"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              NOT(("product" "equals" "update") OR 
            ("component" "equals" "Documentation"))
            </P
></BLOCKQUOTE
>
          to find bugs that are neither 
          in the update product or in the documentation component or
          <A
NAME="AEN2458"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              NOT(("commenter" "equals" "%assignee%") OR 
              ("component" "equals" "Documentation"))
            </P
></BLOCKQUOTE
>
          to find non-documentation
          bugs on which the assignee has never commented.
        </P
></DIV
><DIV
CLASS="section"
><H3
CLASS="section"
><A
NAME="multiplecharts"
>5.5.1.3. Multiple Charts</A
></H3
><P
>&#13;          The terms within a single row of a boolean chart are all
          constraints on a single piece of data. If you are looking for
          a bug that has two different people cc'd on it, then you need 
          to use two boolean charts. A search for
          <A
NAME="AEN2463"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              ("cc" "contains the string" "foo@") AND
              ("cc" "contains the string" "@mozilla.org")
            </P
></BLOCKQUOTE
>
          would return only bugs with "foo@mozilla.org" on the cc list.
          If you wanted bugs where there is someone on the cc list
          containing "foo@" and someone else containing "@mozilla.org",
          then you would need two boolean charts.
          <A
NAME="AEN2465"
></A
><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>&#13;              First chart: ("cc" "contains the string" "foo@")
            </P
><P
>&#13;              Second chart: ("cc" "contains the string" "@mozilla.org")
            </P
></BLOCKQUOTE
>
          The bugs listed will be only the bugs where ALL the charts are true.
        </P
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="quicksearch"
>5.5.2. Quicksearch</A
></H2
><P
>&#13;        Quicksearch is a single-text-box query tool which uses
        metacharacters to indicate what is to be searched. For example, typing
        "<TT
CLASS="literal"
>foo|bar</TT
>"
        into Quicksearch would search for "foo" or "bar" in the
        summary and status whiteboard of a bug; adding
        "<TT
CLASS="literal"
>:BazProduct</TT
>" would
        search only in that product.
        You can use it to find a bug by its number or its alias, too.
      </P
><P
>&#13;        You'll find the Quicksearch box in Bugzilla's footer area.
        On Bugzilla's front page, there is an additional
        <A
HREF="../../page.cgi?id=quicksearch.html"
TARGET="_top"
>Help</A
>
        link which details how to use it.
      </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="casesensitivity"
>5.5.3. Case Sensitivity in Searches</A
></H2
><P
>&#13;      Bugzilla queries are case-insensitive and accent-insensitive, when
      used with either MySQL or Oracle databases. When using Bugzilla with
      PostgreSQL, however, some queries are case-sensitive. This is due to
      the way PostgreSQL handles case and accent sensitivity. 
      </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="list"
>5.5.4. Bug Lists</A
></H2
><P
>If you run a search, a list of matching bugs will be returned.
      </P
><P
>The format of the list is configurable. For example, it can be
      sorted by clicking the column headings. Other useful features can be
      accessed using the links at the bottom of the list:
      <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
>&#13;        <EM
>Long Format:</EM
>

        this gives you a large page with a non-editable summary of the fields
        of each bug.</TD
></TR
><TR
><TD
>&#13;        <EM
>XML:</EM
>

        get the buglist in the XML format.</TD
></TR
><TR
><TD
>&#13;        <EM
>CSV:</EM
>

        get the buglist as comma-separated values, for import into e.g.
        a spreadsheet.</TD
></TR
><TR
><TD
>&#13;        <EM
>Feed:</EM
>

        get the buglist as an Atom feed.  Copy this link into your
        favorite feed reader.  If you are using Firefox, you can also
        save the list as a live bookmark by clicking the live bookmark
        icon in the status bar.  To limit the number of bugs in the feed,
        add a limit=n parameter to the URL.</TD
></TR
><TR
><TD
>&#13;        <EM
>iCalendar:</EM
>

        Get the buglist as an iCalendar file. Each bug is represented as a
        to-do item in the imported calendar.</TD
></TR
><TR
><TD
>&#13;        <EM
>Change Columns:</EM
>

        change the bug attributes which appear in the list.</TD
></TR
><TR
><TD
>&#13;        <EM
>Change several bugs at once:</EM
>

        If your account is sufficiently empowered, and more than one bug
        appear in the bug list, this link is displayed which lets you make
        the same change to all the bugs in the list - for example, changing
        their assignee.</TD
></TR
><TR
><TD
>&#13;        <EM
>Send mail to bug assignees:</EM
>

        If more than one bug appear in the bug list and there are at least
        two distinct bug assignees, this links is displayed which lets you
        easily send a mail to the assignees of all bugs on the list.</TD
></TR
><TR
><TD
>&#13;        <EM
>Edit Search:</EM
>

        If you didn't get exactly the results you were looking for, you can
        return to the Query page through this link and make small revisions
        to the query you just made so you get more accurate results.</TD
></TR
><TR
><TD
>&#13;        <EM
>Remember Search As:</EM
>

        You can give a search a name and remember it; a link will appear
        in your page footer giving you quick access to run it again later.
        </TD
></TR
></TBODY
></TABLE
><P
></P
>
      </P
><P
>&#13;        If you would like to access the bug list from another program
        it is often useful to have the list returned in something other
        than HTML. By adding the ctype=type parameter into the bug list URL
        you can specify several alternate formats. Besides the types described
        above, the following formats are also supported: ECMAScript, also known
        as JavaScript (ctype=js), and Resource Description Framework RDF/XML
        (ctype=rdf).
      </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="individual-buglists"
>5.5.5. Adding/removing tags to/from bugs</A
></H2
><P
>&#13;        You can add and remove tags from individual bugs, which let you find and
        manage them more easily. Creating a new tag automatically generates a saved
        search - whose name is the name of the tag - which lists bugs with this tag.
        This saved search will be displayed in the footer of pages by default, as
        all other saved searches. The main difference between tags and normal saved
        searches is that saved searches, as described in the previous section, are
        stored in the form of a list of matching criteria, while the saved search
        generated by tags is a list of bug numbers. Consequently, you can easily
        edit this list by either adding or removing tags from bugs. To enable this
        feature, you have to turn on the <SPAN
CLASS="QUOTE"
>"Enable tags for bugs"</SPAN
> user
        preference, see <A
HREF="userpreferences.html"
>Section 5.10</A
>. This feature is disabled
        by default.
      </P
><P
>&#13;        This feature is useful when you want to keep track of several bugs, but
        for different reasons. Instead of adding yourself to the CC list of all
        these bugs and mixing all these reasons, you can now store these bugs in
        separate lists, e.g. <SPAN
CLASS="QUOTE"
>"Keep in mind"</SPAN
>, <SPAN
CLASS="QUOTE"
>"Interesting bugs"</SPAN
>,
        or <SPAN
CLASS="QUOTE"
>"Triage"</SPAN
>. One big advantage of this way to manage bugs
        is that you can easily add or remove bugs one by one, which is not
        possible to do with saved searches without having to edit the search
        criteria again.
      </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="lifecycle.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="bugreports.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Life Cycle of a Bug</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="using.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Filing Bugs</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>